Software 


Galactic Cosmic Ray Event- 
Based Risk Model (GERM) 
Code 

This software describes the transport 
and energy deposition of the passage of 
galactic cosmic rays in astronaut tissues 
during space travel, or heavy ion beams 
in patients in cancer therapy. Space radi- 
ation risk is a probability distribution, 
and time-dependent biological events 
must be accounted for physical descrip- 
tion of space radiation transport in tis- 
sues and cells. A stochastic model can 
calculate the probability density directly 
without unverified assumptions about 
shape of probability density function. 

The prior art of transport codes calcu- 
lates the average flux and dose of parti- 
cles behind spacecraft and tissue shield- 
ing. Because of the signaling times for 
activation and relaxation in the cell and 
tissue, transport code must describe 
temporal and microspatial density of 
functions to correlate DNA and oxida- 
tive damage with non-targeted effects of 
signals, bystander, etc. These are ab- 
solutely ignored or impossible in the 
prior art. 

The GERM code provides scientists 
data interpretation of experiments; 
modeling of beam line, shielding of tar- 
get samples, and sample holders; and 
estimation of basic physical and biologi- 
cal outputs of their experiments. For 
mono-energetic ion beams, basic physi- 
cal and biological properties are calcu- 
lated for a selected ion type, such as ki- 
netic energy, mass, charge number, 
absorbed dose, or fluence. Evaluated 
quantities are linear energy transfer 
(LET), range (R), absorption and frag- 
mentation cross-sections, and the prob- 
ability of nuclear interactions after 1 or 
5 cm of water equivalent material. In ad- 
dition, a set of biophysical properties is 
evaluated, such as the Poisson distribu- 
tion for a specified cellular area, cell 
survival curves, and DNA damage yields 
per cell. 

Also, the GERM code calculates the 
radiation transport of the beam line for 
either a fixed number of user-specified 
depths or at multiple positions along 
the Bragg curve of the particle in a se- 
lected material. 

The GERM code makes the numeri- 
cal estimates of basic physical and bio- 
physical quantities of high-energy pro- 


tons and heavy ions that have been stud- 
ied at the NASA Space Radiation Labo- 
ratory (NSRL) for the purpose of simu- 
lating space radiation biological effects. 
In the first option, properties of mono- 
energetic beams are treated. In the sec- 
ond option, the transport of beams in 
different materials is treated. Similar 
biophysical properties as in the first op- 
tion are evaluated for the primary ion 
and its secondary particles. Additional 
properties related to the nuclear frag- 
mentation of the beam are evaluated. 
The GERM code is a computationally ef- 
ficient Monte-Carlo heavy-ion-beam 
model. It includes accurate models of 
LET, range, residual energy, and strag- 
gling, and the quantum multiple scat- 
tering fragmentation (QMSGRG) nu- 
clear database. 

This work was done by Francis A. Cu- 
cinotta of Johnson Space Center and Ianik 
Plante, Artem L. Ponomarev, and Myung- 
Hee Y. Kim of the Universities Space Research 
Association. Further information is con- 
tained in a TSP (see page 1). MSC-24 760-1 


W Sasquatch Footprint Tool 

The Crew Exploration Vehicle Para- 
chute Assembly System (CPAS) is the 
parachute system for NASA’s Orion 
spacecraft. The test program consists of 
numerous drop tests, wherein a test arti- 
cle rigged with parachutes is extracted 
or released from an aircraft. During 
such tests, range safety is paramount, as 
is the recoverability of the parachutes 
and test article. It is crucial to establish 
an aircraft release point that will ensure 
that the article and all items released 
from it will land in safe locations. A new 
footprint predictor tool, called 
Sasquatch, was created in MATLAB. 
This tool takes in a simulated trajectory 
for the test article, information about all 
released objects, and atmospheric wind 
data (simulated or actual) to calculate 
the trajectories of the released objects. 
Dispersions are applied to the landing 
locations of those objects, taking into 
account the variability of winds, aircraft 
release point, and object descent rate. 

Sasquatch establishes a payload re- 
lease point (e.g., where the payload will 
be extracted from the carrier aircraft) 
that will ensure that the payload and all 
objects released from it will land in a 
specified cleared area. The landing lo- 


cations (the final points in the trajecto- 
ries) are plotted on a map of the test 
range. 

Sasquatch was originally designed for 
CPAS drop tests and includes extensive 
information about both the CPAS hard- 
ware and the primary test range used for 
CPAS testing. However, it can easily be 
adapted for more complex CPAS drop 
tests, other NASA projects, and commer- 
cial partners. 

CPAS has developed the Sasquatch 
footprint tool to ensure range safety dur- 
ing parachute drop tests. Sasquatch is 
well correlated to test data and contin- 
ues to ensure the safety of test personnel 
as well as the safe recovery of all equip- 
ment. The tool will continue to be mod- 
ified based on new test data, improving 
predictions and providing added capa- 
bility to meet the requirements of more 
complex testing. 

This work was done by Kristin Bledsoe of 
Jacobs Engineering for Johnson Space Center. 
Further information is contained in a TSP 
(seepage 1). MSC-251 17-1 


@ Multi-User Space Link 
Extension (SLE) System 

The Multi-User Space (MUS) Link 
Extension system, a software and data 
system, provides Space Link Extension 
(SLE) users with three space data trans- 
fer services in timely, complete, and off- 
line modes as applicable according to 
standards defined by the Consultative 
Committee for Space Data Systems 
(CCSDS). MUS radically reduces the 
schedule, cost, and risk of implement- 
ing a new SLE user system, minimizes 
operating costs with a “lights-out” ap- 
proach to SLE, and is designed to re- 
quire no sustaining engineering ex- 
pense during its lifetime unless changes 
in the CCSDS SLE standards, combined 
with new provider implementations, 
force changes. 

No software modification to MUS 
needs to be made to support a new mis- 
sion. Any systems engineer with Linux 
experience can begin testing SLE user 
service instances with MUS starting 
from a personal computer (PC) within 
five days. For flight operators, MUS pro- 
vides a familiar-looking Web page for 
entering SLE configuration data re- 
ceived from SLE. Operators can also use 
the Web page to back up a space mis- 


NASA Tech Briefs, May 2013 


27 


sion’s entire set of up to approximately 
500 SLE service instances in less than 
five seconds, or to restore or transfer 
from another system the same amount 
of data from a MUS backup file in about 
the same amount of time. Missions op- 
erate each MUS SLE service instance in- 
dependently by sending it MUS “direc- 
tives,” which are legible, plain ASCII 
strings. MUS directives are usually (but 
not necessarily) sent through a TCP-IP 
(Transmission Control Protocol-Inter- 
net Protocol) socket from a MOC (Mis- 
sion Operations Center) or POCC (Pay- 
load Operations Control Center) 
system, under scripted control, during 
“lights-out” spacecraft operation. MUS 


permits the flight operations team to 
configure independently each of its 
data interfaces; not only commands and 
telemetry, but also MUS status messages 
to the MOC. 

Interfaces can use single- or multiple- 
client TCP/IP server sockets, TCP/IP 
client sockets, temporary disk files, the 
system log, or standard in, standard out, 
or standard error as applicable. By defin- 
ing MUS templates in ASCII, the flight 
operations team can include any MUS 
system variable in telemetry or command 
headers or footers, and/ or in status mes- 
sages. Data fields can be arranged within 
messages in different sequences, accord- 
ing to the mission’s needs. The only con- 


straints imposed are on the format of 
MUS directive strings, and some bare- 
minimum logical requirements that 
must be met in order for MUS to read 
the mission control center’s spacecraft 
command inputs. The MUS system im- 
poses no limits or constraints on the 
numbers and combinations of missions 
and SLE service instances that it will sup- 
port simultaneously. At any time, flight 
operators may add, change, delete, bind, 
connect, or disconnect. 

This work was done by Toby Perkins of 
Honeywell Technology Solutions Inc. for God- 
dard Space Flight Center. Further information 
is contained in a TSP ( see page 1 ). GSC- 
16091-1 
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